1. Field of the Invention
The present invention relates to token based signing of unsigned binaries.
Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever.
2. Background Art
An operating system is computer software that controls the many different operations of a computer and directs and coordinates its processing of programs. The operating system is made up of a complex set of instructions that schedules the series of jobs (user applications) to be performed by the computer and allocates them to the computer's various hardware systems, such as the processor, main memory, and peripheral systems.
In modern computing environments, the operating system for a computing device (or other computer program) may be downloaded to the device across a computer network from another computer and placed in an area of the computer that normally can not easily be overwritten, and is termed firmware. Downloading the operating system or other firmware is particularly advantageous when the firmware is upgraded or altered in some manner and the user of the computer wishes to take advantage of the alterations or upgrades.
Problems occur, however, when firmware is downloaded. In particular, some files downloaded across computer networks are compromised for various reasons. One example is the case of a “trojan horse” computer program where a malicious user substitutes the correct firmware with the trojan horse. The trojan horse is then downloaded in place of the firmware and begins to perform malicious actions on the computing device which may destroy a user's important files and even may ruin the computer's hardware. Thus, security measures should be in place to ensure that the downloaded firmware is actually the computer program that the user intends to run on the computing device. Implementing these security measures, however, is difficult. In the past these difficulties have stopped firmware developers from making enhancements to computer programs, such as operating systems, and have inhibited the ability to update the computing devices with the enhancements.
Before describing the current security measures in place to prevent problems such as trojan horses, an example computing environment where this problem has specific application is described below.
Multi-Tier Application Architecture
In the multi-tier application architecture, a client communicates requests to a server for data, software and services, for example, and the server responds to the requests. The server's response may entail communication with a database management system for the storage and retrieval of data.
The multi-tier architecture includes at least a database tier that includes a database server, an application tier that includes an application server and application logic (i.e., software application programs, functions, etc.), and a client tier. The application server responds to application requests received from the client. The application server forwards data requests to the database server.
FIG. 1 provides an overview of a multi-tier architecture. Client tier 100 typically consists of a computer system that provides a graphic user interface (GUI) generated by a client 110, such as a browser or other user interface application. Conventional browsers include Internet Explorer and Netscape Navigator, among others. Client 110 generates a display from for example, a specification of GUI elements (e.g., a file containing input, form, and text elements defined using the Hypertext Markup Language (HTML)) and/or from an applet (i.e., a program such as a program written using the Java™ programming language, or other platform independent programming language, that runs when it is loaded by the browser).
Further application functionality is provided by application logic managed by application server 120 in application tier 130. The apportionment of application functionality between client tier 100 and application tier 130 is dependent upon whether a “thin client” or “thick client” topology is desired. In a thin client topology, the client tier (i.e., the end user's computer) is used primarily to display output and obtain input, while the computing takes place in other tiers. A thick client topology, on the other hand, uses a more conventional general purpose computer having processing, memory, and data storage abilities. Database tier 140 contains the data that is accessed by the application logic in application tier 130. Database server 150 manages the data, its structure and the operations that can be performed on the data and/or its structure.
Application server 120 can include applications such as a corporation's scheduling, accounting, personnel and payroll applications, for example. Application server 120 manages requests for the applications that are stored therein. Application server 120 can also manage the storage and dissemination of production versions of application logic. Database server 150 manages the database(s) that manage data for applications. Database server 150 responds to requests to access the scheduling, accounting, personnel and payroll applications' data, for example.
Connection 160 is used to transmit data between client tier 100 and application tier 130, and may also be used to transfer the application logic to client tier 100. The client tier can communicate with the application tier via, for example, a Remote Method Invocator (RMI) application programming interface (API) available from Sun Microsystems™. The RMI API provides the ability to invoke methods, or software modules, that reside on another computer system. Parameters are packaged and unpackaged for transmittal to and from the client tier. Connection 170 between application server 120 and database server 150 represents the transmission of requests for data and the responses to such requests from applications that reside in application server 120.
Elements of the client tier, application tier and database tier (e.g., client 110, application server 120 and database server 150) may execute within a single computer. However, in a typical system, elements of the client tier, application tier and database tier may execute within separate computers interconnected over a network such as a LAN (local area network) or WAN (wide area network).
Thus, with the distribution of functionality between three or more tiers, the machine-centric view of computing diminishes as the need to perform the complete realm of functionality moves away from solely being in the client tier to the other tiers as well. Hence, the type of computing arrangement that is needed on the client tier also changes, for instance the operating system to be used on a computer in the client tier is often downloaded across the multi-tiered network.
Security Measures
When downloading an operating system or other firmware, for instance when a developer has made enhancements to an existing operating system, it is desirable to have security measures in place so that the computer system is not compromised for any reason, such as when a malicious user substitutes the correct operating system file with the trojan horse. One method to provide added security is by using a cryptographic system.
A cryptographic system is a system for sending a message from a sender to a receiver over a medium so that the message is “secure”, that is, so that only the intended receiver can recover the message. A cryptographic system converts a message, referred to as “plaintext” into an encrypted format, known as “ciphertext.” The encryption is accomplished by manipulating or transforming the message using a “cipher key” or keys. The receiver “decrypts” the message, that is, converts it from ciphertext to plaintext, by reversing the manipulation or transformation process using the cipher key or keys. So long as only the sender and receiver have knowledge of the cipher key, such an encrypted transmission is secure.
A “classical” cryptosystem is one in which the enciphering information can be used to determine the deciphering information. To provide security, a classical cryptosystem requires that the enciphering key be kept secret and provided to users of the system over secure channels. Secure channels, such as secret couriers, secure telephone transmission lines, or the like, are often impractical and expensive.
A system that eliminates the difficulties of exchanging a secure enciphering key is known as “public key encryption.” By definition, a public key cryptosystem has the property that someone who knows only how to encipher a message cannot use the enciphering key to find the deciphering key without a prohibitively lengthy computation. An enciphering function is chosen so that once an enciphering key is known, the enciphering function is relatively easy to compute. However, the inverse of the encrypting transformation function is difficult, or computationally infeasible, to compute. Such a function is referred to as a “one way function” or as a “trap door function.” In a public key cryptosystem, certain information relating to the keys is public. This information can be, and often is, published or transmitted in a non-secure manner. Also, certain information relating to the keys is private. This information may be distributed over a secure channel to protect its privacy, (or may be created by a local user to ensure privacy).
A block diagram of a typical public key cryptographic system is illustrated in FIG. 2. A sender represented by the blocks within dashed line (200) sends a plaintext message, Ptxt, to a receiver, represented by the blocks within dashed line (215). The plaintext message is encrypted into a ciphertext message, C, transmitted over some transmission medium and decoded by the receiver (215) to recreate the plaintext message Ptxt.
The sender (200) includes a cryptographic device (201), a secure key generator (202) and a key source (203). The key source (203) is connected to the secure key generator (202) through line (204). The secure key generator (202) is coupled to the cryptographic device (201) through line (205). The cryptographic device provides a ciphertext output, C, on line (206). The secure key generator (202) provides a key output on line (207). This output is provided, along with the ciphertext message (206), to transmitter receiver (209). The transmitter receiver (209) may be, for example, a computer transmitting device such as a modem or it may be a device for transmitting radio frequency transmission signals. The transmitter receiver (209) outputs the secure key and the ciphertext message on an insecure channel (210) to the receiver's transmitter receiver (211).
The receiver (215) also includes a cryptographic device (216), a secure key generator (217) and a key source (218). The key source (218) is coupled to the secure key generator (217) on line (219). The secure key generator (217) is coupled to the cryptographic device (216) on line (220). The cryptographic device (216) is coupled to the transmitter receiver (211) through line (221). The secure key generator (217) is coupled to the transmitter receiver (211) on lines (222) and (223).
In operation, the sender (200) has a plaintext message, Ptxt, to send to the receiver (215). Both the sender (200) and the receiver (215) have cryptographic devices (201) and (216), respectively, that use the same encryption scheme. There are a number of suitable cryptosystems that can be implemented in the cryptographic devices. For example, they may implement the Data Encryption Standard DES) or some other suitable encryption scheme.
Sender and receiver also have secure key generators (202) and (217), respectively. These secure key generators implement any one of several well known public key exchange schemes. Known schemes include the Diffie-Hellman scheme, the RSA scheme, the Massey-Omura scheme, and the ElGamal scheme.
The sender (200) uses key source (203), which maybe a random number generator, to generate a private key. The private key is provided to the secure key generator (202) and is used to generate an encryption key, eK. The encryption key, eK, is transmitted on lines (205) to the cryptographic device and is used to encrypt the plaintext message, Ptxt, to generate a ciphertext message, C, provided on line (206) to the transmitter receiver (209). The secure key generator (202) also transmits the information used to convert to the secure key from key source (203) to the encryption key, eK. This information can be transmitted over an insecure channel, because it is impractical to recreate the encryption key from this information without knowing the private key.
The receiver (215) uses key source (218) to generate a private and secure key (219). This private key (219) is used in the secure key generator (217) along with the key generating information provided by the sender (200) to generate a deciphering key, DK. This deciphering key, DK, is provided on line (220) to the cryptographic device (216) where it is used to decrypt the ciphertext message and reproduce the original plaintext message.
Authentication
In addition to protecting the contents of a transmitted message, it is also desired to provide a way to determine the “authenticity” of the message. That is, is the message actually from the purported sender. A scheme for accomplishing this is to append a so-called “digital signature” to the message. One such scheme is described herein. In this scheme the enciphering transformation fA is used to send a message to user A and fB is the enciphering transformation used to send a message to user B. User A provides a “signature”, P, that may include some specific information, such as the time the message was sent or an identification number. User A transmits the signature as fBfA−1 (P). When user B deciphers the message using fB−1, the entire message is decoded into plaintext except the signature portion, which remains fA−1 (P). User B then applies user A's public key fA to obtain P. Since P could only have been encrypted by user A (because only user A knows fA−1) user B can assume that the message was sent by user A.
Another scheme of digital signature authentication is a generalization of the ElGamal discrete logarithm scheme, using elliptic algebra. Assume a public key ourPub generated with a function of a private key ourPri. The signature is generated by first choosing a random integer, m, of approximately q bits. Next, a point, P=m°(X1/1), is computed. A message digest function, M, is used to compute an integer, u, that is a function of m, ourPri, and the digested version of the ciphertext message and the computed point, P. The computed pair (u, P) is transmitted as the signature.
At the receiving end, the value of the signature is used to compute the point Q=u°(X1/1). A point, R, is calculated using P, the digested version of the ciphertext message and P, and myPub. If R and Q do not compare exactly, the signature is not valid (not genuine). The security of this scheme relies on the computational infeasability of breaking the elliptic logarithm operation or the hash function.
Current Schemes
Using a cryptographic system such as one using public and private keys is one method that is currently used to attempt to ensure the security of a piece of firmware, such as an operating system when it is downloaded to a computer. Thus, one scheme downloads new firmware to a device that is signed with a secret key. Once downloaded, the firmware's signature is inspected by the device to ensure that it is authentic. If approved, the new firmware is made active on the new device, the new device re-boots, and the new firmware is used, for instance by the device using the new firmware image as its operating system This method is disadvantageous because it does not give a third-party firmware developer the ability to sign a piece of developed firmware. This means that the third-party developer has no way to enhance firmware and implement it on a machine.
One method that allows a third-party to develop and implement firmware is by providing the third-party with the secret key so that they can sign the firmware themselves. Serious drawbacks exist, however, if the private key escapes from the third-party and enters the general population, which often happens. In addition, the end-user may be malicious as well. If a malicious user receives the private key or it slips out into the general population, then whoever knows the key can compromise any computing device using such a key, which is disadvantageous.